1. The Field of the Invention
The present invention relates to rolling-forward through logs associated with a number of information stores to cause each information store to be in a consistent state with respect to the other information stores. More specifically, the present invention relates to systems, methods, and computer program product claims for identifying a common point in time across a number of the logs and rolling-forward in each log to the common point in time.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., database management, scheduling, and work processing) that prior to the advent of the computer system were performed manually.
At times, a single task can involve modifying data stored at a number of individual storage locations. In some cases, data stored at one individual storage location is related to data stored at one or more other individual storage locations, such that it is important that all the related data be modified together. For example, when transferring funds from a first account at a first back to a second account at a second bank, data associated with the funds of the first account can be modified to debit the first account and data associated with the funds of the second account can be modified to credit the second account. Unfortunately, when modifying related data that is stored at different individual storage locations, there is always some possibility that the task being performed to modify the data might be interrupted (e.g., a user may halt performance of the task or a computer system fault may occur). This can result in some of the related data being modified, while other related data is not modified. When only some of the related data associated with a task is modified, the individual storage locations storing the modified data are often referred to as being in an “inconsistent state” with respect to the individual storage locations storing the unmodified data.
In some cases, data modification tasks are performed in a distributed system where modules (at the same computer system and/or at different computer systems) connected to a common infrastructure interoperate and communicate between one another in a manner that may be transparent to a user. These modules may modify data stored at different individual storage locations by communicating in the background to transfer user commands and program responses. Due to the increased complexity of distributed systems, including the possibility of multiple points of failure, there is an increased chance of a distributed system placing a number of different individual storage locations in an inconsistent state with respect to each other.
Identifying the cause of an inconsistent state often requires a level of technical expertise beyond that of the average user. Further, even if the cause of an inconsistent state is identified, it may require a significant amount of time for a user to transition a number of different individual storage locations out of the inconsistent state (e.g., by entering user commands to reverse the effects of previously performed data modifications). To reduce the chance that individual storage locations will have to be transitioned out of an inconsistent state by a user, individual storage locations are often backed-up (e.g., to tape media), at regular intervals (e.g. once a day, once a week, etc.).
A back-up can preserve the state of a number of different individual storage locations as of the time the back-up is performed. If, after a successful back-up (e.g., backing-up a number of different individual storage locations that are known to be in a consistent state), one or more individual storage locations transition into an inconsistent state, these individual storage locations can be returned to a consistent state by restoring data from the back-up. However, depending on the back-up interval, a significant amount of data may be lost when restoring from back-up. For example, if back-ups are performed every day at 11:00 PM and an individual storage location transitions into an inconsistent state at 10:00 PM, twenty-three hours of data may be lost when the individual storage location is restored from the last back-up.
To further reduce the problem of data loss then transitioning out of an inconsistent state, transactional systems can be utilized. A transactional system treats a number of related data modifications as a single atomic unit (commonly referred to as a “transaction”). That is, either all the related data modifications are performed or none of the related data modifications are performed. To help maintain this atomicity during a recovery, an entry for each related data modification is written to a log when the data modification is successfully completed. Thus, a log can be utilized to maintain a record of all the data modifications that occur between back-up intervals.
When all the related data modifications associated with a transaction are successfully completed, an entry can be written to the log indicating the transaction was “committed.” When a committed transaction is subsequently lost (e.g., due to a computer system failure), log entries associated with the committed transaction can be processed to “redo” the related data modifications (commonly referred to as “roll-forward”). On the other hand, when all the related data modifications associated with a transaction do not complete, an entry can be included in the log indicating the transaction was “aborted.” When a transaction is aborted, the log entries associated with any data modifications that were performed can be processed to “undo” these data modifications (commonly referred to as a “roll-back”). Thus, a log helps ensure that individual storage locations can be transition out of an inconsistent state with minimal loss of data.
To transition an individual storage location out of an inconsistent state, the most recent back-up is typically loaded and then a log associated with the individual storage location is rolled-forward to the desired recovery time. In some cases, when a number of storage locations are in an inconsistent state, a number of logs must be rolled-forward to the same desired recovery time. This can be problematic, as a number of individual storage locations may not have a common understanding of time.
Individual storage locations may have different clock settings, may operate in different time zones, or timing of individual storage locations may drift due to inevitable differences in the components of the individual storage locations. For example, a first individual storage location may indicate that one of a number of related data modifications occurred at 5:00 PM., while a second individual storage location indicates that another of the number of related data modifications occurred at 5:10 PM. Thus, rolling forward to 5:05 PM may result in the first and second individual storage locations being in an inconsistent state. Further, even if individual storage locations could be precisely synchronized, network conditions, such as, for example, differing transmission speeds, variable latencies or changing members of hops between individual storage locations can affect an individual storage location's perception of time.
Therefore, what are desired are systems, methods, and computer program products, for establishing a common understanding of time across a number of logs.